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ABSTRACT 


The purpose of the feasibility study is to establish an 
automated data base system for Naval Electronics Engineering 
Center, Vallejo, California. The three divisions, namely, the 
Financial, procurement and program manager's divisions, were 
analyzed aS a Separate entity by taking their present methods 
of operation and determining which methods lend themseives to 
automation and propose a conceptual EDP system to handle the 
new data structure. After combining the applications of each 
division, a file design structure along with the associated 
hardware equipment and recommendations for further evaluating 


the overall performance of the system were supplied for NAVELE™, 
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J. BACKGROUND AND GENERAL PROBLEM STATEMENT 


The Naval Electronies Systems Engineering Center (hereafter 
referred to as NAVELEX), Vallejo, California is tasked with the 
mission of providing eleetronics material support for eleetronic 
systems and individual equipment onboard ships and government 
field activities as assigned by the Naval Electronics Systems Com- 
mand. The majority of work performed on these electronic pieces 
of equipment is aecomplished by reimbursable work (e.g. the spon- 
soring activity of the particular ship or field activity sends an 
allocation of money for the work that NAVELEX is to perform). Thus, 
there iS no operating budget from appropriated funds to sustain 
their aesaacene funding being provided only from the various spon- 
Serine activities. Though NAVELEX has an aeeounting section for 
intecnal budgeting, the authorizing aeeounting activity (AAA) for 
reporting NAVELEX's budget to higher authority is the responsibility 
of NSC Oakland. In addition, NSC Oakland is responsible for the 
eontracting of items with a value over $250. 

To ascist the commanding offieer in accomplishing the above 
Stated mission is the task of the Planning and Program Management 
and Enginecring departments respeetively. The Planning and Program 
Management department responsibilities include advance planning on 
major task assignments, financial management and material management 
for all clements of the command and the command itself, and for the 
planning required For the development und support of budget, long 
range, emergency and oLther command plans. Vhese responsibilitics 


and tasks are further divided among three divisions. These divisions 





presently conduct their business without the aid of automation and 
are the subject of the feasibility study presented later in the 
paper. The Engineering department is responsible for the technical 
design, development and systems engineering on all task assignments 
and for the maintenance of plan files and for library and reproduc- 
Peo services. The Engineering department was not considered in 
the feasibility study because it was determined in the preliminary 
investigation that computer terminals already existed as an aid to 
attaining its goal. The only problem with the system as it now 
exists is that there is no hardeopy capability. All data is input 
on a display terminal to the computer facility at Lawrenee Berkiey 
Laboratories (LBL) and the computer printout is mailed to NAVELEX. 
If a telephone line hook-up was established between LBL's eomputer 
and a line printer at NAVELEX, the problem of meeting thc time con- 
straints imposed by the different task projects would be satisfied. 
NAVELEX's two departments were faced with the problem of improv- 
ing their response time and thereby increase their effeetiveness in 
Gicwaress of material status for all assigned tasks, various account- 
ability reports, and for the maintenance of plan files. To determine 
what the impact of automating some of their present techniques would 
have in solving their problem, a feasibility study was conducted. 
The study was restricted in the sense that any eomputerized system 
conceived would have to be operated by in-house personnel due to a 
government freeze on hiring. This caused additional factors to be 
eonsiderecd. The personnel selected to opcrate the system would have 
to be retrained. The impact this retraining would have on the oper- 
ation of the systcin by switching from a manual operation to a mech- 


anized operation must be considered. These faetors are not discussed 





mipete senesis but are merely mentioned to acquaint the manager 
with the possible pitfalls that lie ahead. 

Sree Nowszeneraily accepmed procedure exists for determining 
what steps to follow in conducting a feasibility study, the 
choice of steps selected for each division in the Program and 
Planning Management department was to determine the required 
reports that had to be generated by their present methods of 
operation, what methods lend themselves to automation and to 
produce an electronic data processing system (EDP) to handle the 
new automated techniques. Chapter two discusses the financial 
division, Chapter three describes the procurement division and 
Chapter four discusses the operation of the program manager's 
division. Chapter five combines aljJ three divisions in the anal- 
ysis of oe organizations and produces @ conceptual system for 
the Planning and Program Management department. In addition, 
recommendations are presented for further evaluation of the overall 


effectiveness of the system. 
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lI. FINANCIAL DIVISION 


View iianeiaiedavision 1S responsible for preparing financial 
reports for the procurement division and for their submission to 
the authorizing accounting activity (AAA), NSC Oakland, and for 
Supervising timekeeping and payroll opertions. The following 
sections all discuss the two functions of the financial division 


namely, payroljs and contracts. 


A. PAYROLL OPERATION 

The present method of handling payrolls consists of each shop 
center submitting a weekly worksheet to the financial payroll 
section that contains all the hours earned for that week including 
leave hours, sick hours, and assignment to temporary additional 
duty of their personnel. (Presently there are 790 employees 
assigned to NAVELEX). Onee in the financial division, two person- 
nel are assigned to transcribe the hours from the worksheet onto 
time cards and to validate any overtime. Overtime must be 
validated because salaried employees are not allowed overtime 
whereas hourly employees are allowed overage. This normally takes 
two working days before the time ecards are routed to the account- 
ing section. The accounting section deducts the total dollar amount 
that the employee worked on a particular job order (at anytime 
there are at least 800 job orders outstanding) from the balance of 
Puemallocced dollars assigned to that job order. If the employee 
Verse on a numver of daliferent job orders during the week, it is 


possible that his timé ecard would have to be processed by two or 


1 





morc accountants, since each accountant is responsible for only 
Peitae LION OL the Ob orders that the financial division has out- 
standing. After all the time cards have been verified and posted 
to the accounting ledgers, they are sent to NSC Oakland where 
they are then keypunched and listed onto two magnetic tapes. One 
tape is retained by NSC Oakland to update their accounting records 
for reporting to higher authority since they are the designated 
accounting activity for NAVELEX, Vallejo. The sccond tape is 
forwarded to the Regional Disbursing Center at Treasure Island 
Where the employees' checks are actually printed. After all of 
the checks have been printed, a designated person from the 
financial division receipts for the checks and issues them to the 
various shop centers. This entire cycle is then repeated for the 
next meelovammarksheet. 

The problem that the financial division has with the above 
procedure is that of getting the time cards to Oakland in a 
timely fashion; in effect they are faced with improving their 
response- time while at the same time retaining some semblance 
of in-house accountability control. The problem of timely report- 
ing is caused by the nature of work performed by the employees. 
One employee may work on aS many as five different job orders dur- 
ing the week thereby requiring his time ecard to be proccssed by 
two or more accounting personnel. This can cause a delay of two 
additional work days before the total package of time cards are 


ready for submission to NSC Oakland. 


Analysis For A Conceptual PDP System 
The realization of an improved method of solving the dilenima 
Pie@ietae@e@s NAVELEX Vallejo required an cvaluation of their input, 


Bl 





data base, output and processing requirements. Input requirements 
Could encompass a large area, but since this portion of the study 
was concerned with reviewing the payroll operation, the only 
areas that were considered for implementation in the computer 
system were the media, frequency of input, format of the input, 
and the type of transactions. The data base requirements considered 
the list of data elements including whether the elements were 
alphabetic, numeric or alphanumeric, indexing the entry into the 
data base, and the format of the data base. In regard to out- 
put requirements, the study considered the output media, the 
retrieval mode, format, and the output descriptors. Lastly, the 
processing requirements analyzed consist of the type of arithmetic 
operations required. The different operations required to get 
useful eee nerul output would consist of searching, sorting 
and editing. 

To formulate the input requirements, it was determined that 
all the time cards had to be processed at the end of each week and 
further that the most important information (as far as the account- 
ing section is concerned) is the dollar amount and number of hours 
credited to the employee while working on a particular job order. 
In order to incorporate these two requirements, it was decided to 
use a batch schedule to update the master file.and to run the 
required weekly update. The decision to employ a batch system 
vice a time sharing system as based on the fact that the employee's 
work sheet is only completed at the end of the week, thus preclud- 
ine any daily update to the file. The input media used consists 
of punched cards, which gives™“the flexibility of having a direct 


visual copy of what was input into the system in case the system 





Sow Orekiat aneeCrror is deteeted. The input format, shown 
in figure 1, avoids having to input the entire reeord for each 
update. The type of transaetions involved would be the ehanging 
Of fields (e.g., inereasing the hourly rate field if an 

employee reeeived a raise or deleting entire records in the 

case that an employee was dropped from employment). Also, an 
option was left to increase the size of the master file. This 


option satisfied the addition requirement of the input. 
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DATA INPUT 


Pereure 1 


The data base had to be structured so that pertinent 
information required by the aceounting seetion eould be readily 
attainable. This was aeeomplished by having two data files 
Pigteoameemerced forming a “Payroll” file. One data file is 
called the "Dictionary" file which consists of the following 
data clements: employees' name arranged in alphabetie order, 
social security number of the employee, and the hourly rate of 
pay if the employee is an hourly worker or the salary rate if the 
employee is salaried. The seeond data file is called the “Money 
Order" file whose eomposition is job order number, dollars 


alloeated (which is the total dollars alloeated for that job), 


Ly 








- 


number of hours worked, and the social security number of the 
employees who worked on that particular job order. These two 
files are then merged to produce a master file called a 

"Payroll" file. The format for these data structures is shown 

met ietire 2. It is obvious that the "Payroll" file (see 

figure 2) must consist of the following data elements: nanie, 
social security number, number of hours worked and the rate of 
pay, Since this is the information that NSC Oakland requires for 
aceounting purposes. The eontents of all the data files are both 
numerie and alphanumeric. 

The output information required by the accounting section 
must be in a readable and usable form. The simplest media 
BowoOotLadininge this output is to have a hard copy capability 
that is lied by a low-speed printer. A low-speed printcr 
was decided upon vice a medium or high speed printer because of 
the cost involved, since the output does not have. to be retrieved 
rapidly. A likely output format would key on the job order 
number field listing the job order in sequential order and within 
this job order an alphabetical ordering of the employees’ names, 
with the number of hours eaeh employee worked. A sample output 
listing is given in figure 3. There are various options ‘or 
outputting the data. As mentioned earlicr one report would be 
in job order sequenee and another by alphabetical sequence of the 
employees’ name. An example of this report is shown in figure +t. 


The output retrieval mode would have to be by batch keying on 


multiple descriptors. 


dE. 
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The proccssing requirements must include the capability of 
sorting records either by name, social security number, job order 
number, ete. Also, if any changes are made to a record it is 
desirable that only selected fields be edited without having to 
input a complete new record every time a change is made. There- 
fore this feature must be added to the system. The search of the 
file is done sequentially. 

Using the above analysis, a conceptual EDP system is 
illustrated in figure 5. A detailed analysis of the file struc- 
ture required to implement the system is given in Chapter five. 
This operation would be based on having the shop center supply a 
person to validate all overtime and leave of personnel assigned 
to their centers. This person would kcypunch the time cards 
and submit them to the computer. The computer would produce a 
magnetic tape for NSC Oakland and a listing printout for the 
financial division's in-house use (see figure 6). This automated 
procedure would climinate at least four working days from the 
present manual processing time. 

To handle this procedure, the system would not require a 
large memory capacity so a minicomputer with a capability of add- 
on memory could be used. Since NAVELEX is concerned with getting 
the magnetic tape to Oakland as soon as possible (and at the same 
time retaining a hard copy to validate internal control), a 
medium speed magnetic tape unit for rapidly producing tapes, a 
low-speed offline printer for producing a hard copy to be 
retained by the financial section and a card reader to read the 


input are required. 
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Bee CONPFRACTS 


Contracts fall into two basic categories, Indefinite Delivery 
and One Time Purchase contracts. In this chapter Indefinite 
Delivery will be discussed because it is the only type of contract 
that the financial section handles directly. 

Indefinite Delivery contracts are contracts that have already 
been established with a contractor due to some previaus demand 
experience or request. Once the decision is made by the project 
manager that contract support is required, the financial manage- 
ment division is responsible for administering financial control 
of the contract request which consists of assigning a requisition 
number and cbligating funds against that job order and for sending 
Eieeeobligation fo NSC Oakland, and for cffecting purchase action 
which calls for the contractor to give a dollar amount estimate 
for the requested material or services. 

The problem that the financial section faces is to assure 
that reported outstanding obligations are, in fact, outstanding 
and if the material or services have been received to make sure 
that receipts are posted mn a timely fashion so that payment to 


contractors can be effected. 


Mieiyois Tor A Coresprtudlyenre System 


The above problem cannot be solved by the financial division 
alone because they depend on the shop ecntcrs to provide signed 
Pecenpt Copies to etfect payment. in addition, the financial 
Givision relies on the procurement and planning (ay Vo. Oh ke 
Peerwdem~nie status Of OoOulsStending requisitions. Since the require- 


ments for the conceptual EDP system are very similar to the EDP 


22 





requirements for the contract portion of the procurement and 
planning division, an alalysis for the financial division will 
be delayed and combined in the analysis of the procurement section 


Olt GOntracts discussion. 


TTT. MANAGEMENT ANALYSIS AND ADVANCE PLANNING DIVISION 


The management analysis and advance planning division will be 
hereafter referred to as the procurement division since this is 
five only portion of the operation that a request for a feasibility 
study was made. The procurement division has the responsibilitics 
for the establishment of NAVELEX's annual Indefinite Delivery 
contracts, for initiating One Time Purchase contracts through the 
appropriate procurement contracting office, NSC Oakland, and Ow 
the survcillance and administration of the contract after award. 
The remaining paragraphs of the chapter will discuss the present 
method of operation, the problems associated with the method and 
offer an alternative approach to enlarge the overall effectiveness 


of the division's operation. 


A. PROCUREMENT DIVISION OPERATION 

The basic decision of whether contractor support is required 
Gaeae particular job order rescs with the shop centcr responsible 
for the work associated with the job order. Where contractor 
support is desired, or required, a contracting specialist 1s 
available in the procurement division to provide GONnLrac bime 
advice. The contracting specialist reviews the request from the 
shop center and forwards the document to the financial division 


where it is verified that funds are either available or exhausted 





Pomme job order. If funds are available after verification the 
eontracting speeialist prepares the necessary procurement request 
to the contracting office (usually, NSC Oakland) if the request 

is for a One Time Purchase. If the request can be filled with 

an Indefinite Delivery contract no assistance from NSC Oakland is 
required. When the request is forwarded to NSC Oakland, the 
contracting speciaiist must then await a reply from the contracting 
office before any action can be taken. However, the procurement 
division's contracting specialist maintains liaison with the 
contreeting office as required to assure ary questions that may 
arise arc answered and to assist the eontracting officer through- 
out the preawarding process. When the contract has been awarded, 
Gopics are provided to the shop centers concerned to assure 
eonsisteney with the original requirements. When changcs are 
mequared to an existing contract, the shop center will initiate the 
request and it will be routed through the program manager, procure- 
ment division, financial division for aceounting purposes, and 
finally to the contracting office. If immediate ehanges are re- 
quired, the program manager is notified. He works with the 
eontraeting specialist who advises the applicable contracting 
officer to inform him of the immediate action required. With the 
contracting officer's approval, the change is then accomplished 
and the paper work follows. In the case of Indefinite Delivery con- 
tracts, the contracting specialist goes direct hy Sho sine secon tracker 
with the request and monitors the request until the material or 
Serviees are delivered. After the receipt of the materials, the 


eontracting specialist determines the Gudlittvedi(eeee) taba ieintiy, sont 


aly 





the materials and passes the information to the financial Givision 
£0 tat the contractor may we paid. 

The primary problem facing the procurement division is the 
need to shorten the response time from the shop center's initial 
reguest for contractual serviccs until the contracted material is 
received. An additional drawback is the inability of NAVELEX to 
contract directly (without going through the contracting office, 
NSC Oakland) any One Time Purchase contract with a dollar emount 
exceeding $250. This factor is a substantial restriction for 
NAVELEX's operation because most of the contract requests are in 
the range of fifty thousand dollars. 

Unless NAVELEX is authorized a larger dollar ceiling thcre 
will always be a significant time delay. This delay occurs 
because the document requesting contract support must be mailed 
to NSC Oakland and normally there will be additional delays 
because of constant telephone communications with the contracting 
officer at Oakland trying to obtain information from the contract- 
ing specialist. The only portion of the problem that NAVELEX can 
gniluence 1s @he currency of the Indefinite Delivery contract and 


of providing current status of One Time Purchase contracts. 


Ceueceneuele UE oyotem For Procurement Division 
Inespunpese on the feasibality study is to investigate 
alternative methods to minimize the response time from the initial 
request for contractor support until the receipt of the material 
from the contractor. As noted from the above operation, the 
only influence that the procurement division can bring to bear 


on the problem is to validate the curreney of the annual 


ae 





Indefinite Delivery contracts so as to alleviate the necessity 

fer renegotiating Glapscd contracts and for maintaining current 
status on the One Time Purchase contracts. These two areas will 

be discussed in an effort to offer an alternative automated approach 
to the present method of operation. The following discussion 
describes the input, data base, processing and output requirements 
of the two areas and propose an EDP system to satisfy the require- 
ments. The input analysis considered the frequency of input, 

input media, format of the input and the type of transactions 
processed. The data base requirements considered the list of 

data elements, including whether the elements are alphabetic, 
numeric or alphanumeric and the format of the data base. In regard 
to the processing requirements, the study considered the type of 
operations required: Scirehiime Sorting and editing. Lastly, the 
output requirements consisted of the output media, format and the 
frequency of the output. 

In the input analysis phase it was determined that there are 
two types of input which the contracting specialist must input to 
the system in meeting his responsibilities. The first input type 
is the maintenance and updating of each Indefinite Delivery con- 
tract. It was decided to use a timesharing schedule vice a batch 
schedule because any request for an Indefinite Delivery contract 
update occurs on demand and not all contracts require updating. 
The input media would consist of terminal displays which give the 
flexibility of rapid update of a reeord. The input format shown 
in figure 7 avoids having to display the entire record each time 
sclliected Iaelds Wade to be tiptmed. The transuctions involved are 


the manipulations of selected field that the contracting specialist 
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an 


may want to change is the "dollar amount" ficld. The second input 
requirement is the maintenance of the current status of One Time 
Purchase contracts. It is obvious that this function must occur 
on demand because different contractors provide status only on 
their contracts. Since there is no guarantee that all the status 
will be received Simultaneously, it was decided that a time shar- 
ing demand input schedule would satisfy this requirement and the 
input media would be terminal display CRT units. The format of 
the input is similar to the format of figure 7. Normally, the 
only fields that would change are the cstimated delivery date (EDD) 


eras tatus fields. 


-CONTRACT Pio o Jess Dh, 


NUMBER BE UPDATED BE UPDATED 





TERMINAL DATA INPUT 


Figure / 


The data basc must be structured so that useful am 
understandable information required by the procurement division 
can be readily obtained. This iS accomplished in two ways. For 
Indefinite Delivery contracts, the data base required is callcd 
the "Annual ID Contract" file and it’s compositionis Indefinite 
Delivery Contracts arranged in contract numbcr order that are 
active in the current fiscal year. The format of the filc is 
niiltistrated in fieure § and the list of data elements contains 
tie Contract number, job order number, material of Service 


provided, dollar amount allocated for the contract number and the 


a 





date the contract elapses. The contents of the fields in the file 
are both numeric and alphanumeric. For One Time PurchaSe contract 
status, the data base file is called the "OTP" contract file and 
consists of the following data clements: contract number, brief 
description of the requirements, status, job order number and dol- 
lar amount allocated. It's composition is shown in figure 9 and 
the contents of the file are alphanumeric and numeric. 

The processing requirements must include the capability of 
sorting records by contract number, dollar amount, cstimated 
delivery date, cte. In addition the ability to edit sclected 
Fields without displaying the cntire record must be built into the 
system. The searching of the files is accomplished by direct 
access. 

The aa required by the procurement division must be in an 
easy-to-read form. There are two media for accomplishing this 
form. Onc is to have the display terminal output the status that 
management or the shop center requires immediately, however there 
is no hard copy capability with this media. A second media that 
Supplies a hard copy capability would be a low or medium speed 
Peigber- there are various options Pereolwtputtine the data; an 
example output for Indefinite Delivery Contracts is shown in 
figure 10. This output would list all contracts that would elapse 
Pema wepceiticd umber of dayS im contract numbcr scquence. For 
One Time Purchase Contracts the format of the output is shown in 
figure 11 and would key on the dollar amount field and list only 


aiGsereComtracrommver a certain dollar amount. This would be 


valuable information if the precurement division was comtemplating 
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Cancelling some of the high value non-critical contract items in 
order to reprogram the money to order highly critical items. 

To handle the above requirements a conceptual EDP system is 
shown in figure 12. The file organization structure necded to 
implement this system will be described in chapter five. The sys- 
tem would consist of a CRT display terminal, a low speed printer 
for allowing a hard copy capability, offline disk storage to 
rapidly bring files online for immediate status information and 
win Leomputer to sequence the operations of the other peripheral 


devices. 
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IV. PROGRAM MANAGERS DIVISION 


For every work request that NAVELEX Vallejo receives from a 
sponsoring activity, a program manager or project manager is as- 
Signed by NAVELEX to monitor the work request through to completion. 
The duties of a program manager include serving as the contact 
point tor the receipt, coordination and correlation of customer 
program requirements, cnsuring timely and efficient completion of 
task assignments, advising management of potential difficulties 
and delays in critical task assignments, determining time and cost 
trade-offs in meeting customer requirements, monitoring the prog- 
ress of all assigned projects and preparing the necessary reports 
to management and directing distribution of funds for the accom- 
plishment of assigned program tasks. The remaining portions of 
the chapter describe the program manavers' present method of 
accomplishing his assigned duties and offer an alternative auto- 
mated approach to improve the overall effectiveness of the oper- 


ation. 


A. PROGRAM MANAGER'S OPERATION 

When a request for servicing some type of equipment is received 
from a sponsoring activity, NAVELEX assivns a program manager with 
expertise in the operation of that equipment to be in charge of 
the project. Once the program manager is assigned he must decide 
on the number of steps that are needed to complete the work re- 
quest. Each step must be assigned a job order and given to a shop 


eenter where the shop center analyzes the number of personnel it 
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will have to supply, since the shop center actually does the work 
on the step. Any materials or services that the shop centers re- 
quire are referred to the program manager who in turn has to con- 
sult with the procurement section to ascertain whether a contract 
exists or if bids are needed to establish a new contract. Deter- 
mining that the contract exists (or after awarding new contracts) 
the program manager must wait for the status of the contracts. 

In some cases the materials for some of the steps will be received 
before other steps which could effect the completion of succeeding 
steps. The program manager must constantly be cognizant of the 
bottleneck that could occur. If the situation arises where the 
dollar amount of the required materials or services outweighs the 
dollar amount of the job order, the program manager must determine 
time and cost trade-offs in meeting the sponsoring activity's 
requirements. The alternatives available to the program manager 
are to request that the sponsoring activity increase the dollar 
allocation for the work request or to attempt to refurbish some 

of their old equipment to conserve money. If the work proceeds 

as scheduled, the material will be receipted for by the shop center 
and the paperwork passed on to the program manager who must pro- 
Vide a copy to the financial section so that the contractor can 

be paid. 

The problem that the program manager faces with the above 
operation is to get status in a timely fashion of all outstanding 
Semeleaets tial Mmayenecessatate changing priorities. Presently, 
this is done manually be calling either the contractor or NSC 
Oakland for the current status of contracts. This interrogation 
may take two or three a if the telephone lines are busy or if 


NSC Oakland has to query their computer because status has a Low 
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priority in their computcr operation. When this status is received 
ait must be sent to the management personnel section in an under- 
standable format so that time and trade-off considerations can be 
weighed and a decision reached on how to complete the assigned 


work request. 


Biibvows Of Moneeptual EDP System 


To alleviate or minimize the problem associated with the 
above operaticn an analysis of the present techniques of opera- 
tion lead to the conclusion that the operation could indeed be 
automated. The succeeding paragraphs will analyze individually 
the input, processing, data base and output requirements, respect- 
ively. The components of the input requirements include the fre- 
quency of input, content of the input, i.e. whether the input is 
alphabetic, numeric or alphanumeric, time of input, input mode, 
format and the types of transactions. The processing requirements 
consist of searching, method of retrieval, editing and sorting. 
The data base requirements consist of the list of data elements, 
format of the data hase and the data structure. Finally, the 
output requirements consists of the format, output mode, frequency 
of the output and the content of the output. 

In the input requirement phase of the analysis, the data that 
the program manager must have to assist him in meeting his respon- 
Sibilities consists of two types of input. The first type of 
input is the establishment of a record called the "Contract" 
record for each contract number (sec figure 13). At the very 
minimum, the amount of information needed for creating the input 
for the "Contract" reeord is the contract nunber, a brief identi- 


fication of the materials or services required and the dollar 
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amount allocated. The content of the input is both alphanumeric 
and numeric and the frequency of inputting this data is obviously 
on demand because awarding a contract to a bidder is directly 
related to the dollar amount of the bid. However, it is recommended 
that new "Contract" records only be established at the end of 
NAVELEX's daily operation and that it be accomplished as a batch 
process. 
The second type of input that the program manager must have 
at his disposal is the ability to query the "Contract" records for 
status (see figure 14). The most important field to the program 
manager is the estimated dclivery date (EDD). The only input that 
must be Supplied by the program manager is the contract number. 
The frequency of input is the same as the first type of input with 
the exception that the information must be supplicd as soon as it 
is needed so that the input mode must be realtime CRT terminals. 
The only type of transactions applicd in the input phase of the 
analysis are editing different fields of the associated records. 
The. components of the processing requirements must be capable 
of allowing the program manager the ability to selectively search 
for status on "Contract" records. A sequential search would not be 
feasible if many records were on file, therefore the solution would 
be to have the capability of direct access. Since the status of 
a contract is constantly changing until the material is actually 
receipted the option of being able to update the record is required. 
This updating would include the editing of certain fields of the 
record if the status is changed or if a substitute item is exchanged 
for the oricinal material. Tee third processing requirement is the 


capability of deleting recoreds from the file onec the materials 
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have been reccived. The retrieval mode for bringing records online 
would be direct aecess in order to spced up the computer time per 
request versus the slower sequential mode. The final requirement of 
sorting is a sequential sort keying on the contraet number. 

The data base required to satisfy the input and processing 
required would consist of two files called the Contract file and 
the Name file. The "Contraet" file which is made up of “Contraet" 
records has the composition of contraet number, dollar amount 
alloeated, a bricf identification of the major piece of equipment 
being refurbished and the date the eontraet was established. The 
"Name" file contains identification of the material needed in the 
renovation of the equipment, contract number, current status, 
job order number and the cost of purchase. These files are then 
merged to create a master file called the "P.M." file with the 
Format for these data structures shown in figure 15. The "P.M," 
File consists of the eontract number, a listing of the materials 
ordered under the contract number, status, and the cost allocated 
for the matcrial. 

The output information required by the program manager must 
be in a readable and usable form. There are two media for obtain- 
ing the required output. To keep management informed on the 
dollar cost and any delay in receiving materials, one type medium 
is to have a hard copy capability that is supplied by a line 
printer. This report would be presented to management on a weckly 
basis. An example output listing is given in figure 16 and would 
hey Ene COltdetsmumber ticid Jasting the contract numbers in 
Sequel Older em tOuKeCD Bapeprocram manager abreast of the 
ehanging status of matcrials ordered, the second medium that would 


be employed is a CRT display. {ts format is similar to figure l7. 


a 





ada Me NOUS iG 


Agta. Wed 


| 


FOND) JOMTY 


YIAdNO TS Ogee Eons mimod WaIdaWnaNn 





GO’ | AVITOd }LNaNYNO | LYW [LOVYLNOD 





GT eansty 


sSUADVNVN WVdO0dd 


Siti ean 





THWINOTW 





AS VHOUNd SOLVIS YaIGwnn VIYALVN 


4O £800 |JNdddND |LOVALNOD JO ANVN 


ala ravines 


YSAEWONn 


diva !dIn0d WVIIOd |LOVYLNOD 


U() 


Doeeo0 OF 
aol” elelees 
00°0S S$ 


LSOO 


QT aInsTt yz 


IJNILSTT YaLNdWoo 


9Z46T Trady 


SZ6T oun € 





diVd AYWAAITAC GaALVNILIS 


T1dNos 
CIATION 
CAVAICIONIVA 
(add THs 

SNLVLS 


MOGs siicae LOCZEN 


aLVId £Vdi 
FONVTA 


MAYOS XATI 


GCavydduO ‘IvldsaLVN 


-UdGWNON LOVELNOO 


ty] 





00° 000‘0E 


00°96‘ ET 


GO<0S5e SE 


00°000°0E€S 


LSOO 


ZT aInsty 


ONILSIT SOLVLS WIYdlVN 


une l= lere ML 1Sinie 


SH6ET-~ETTO-TZEGN 


eMoltlccUrtoneN 


Lose al aevenen 





YdGWON LOVYLNOO 


YINYOISNVAL TVOTdLOd Td 


peTeour) 


quawdtys 
Tetj4ed 


peddryus 


eunt’ Qe ddd 
palapzoyorg 


SHLLVLS 


“TWIYALWN dO ANVN 


2? 





Using the knowledge of the above analysis, a coneeptual EDP 
system is depicted in figure 18. This operation would be based 
on only having the users trained in the operation of the CRT 
display. The file organizatinn associated with this system will 
be discussed in Chapter five. The system would require off-line 
storage versus loading magnetic tapes, it was decided to have the 
files stored on disk. A small minicomputer will be used to bring 
the monitor or supervisor program on-line (from magnetic tape) 
and to sequence the other peripheral devices. A medium or low 
spced printer is required to generate the weekly reports for 
management and a CRT display terminal would be used for creating 
new "Contract" records, editiny files and deleting records. This 


would eliminate the need for a card reader. 
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V. FILE ORGANIZATION & CONCEPTUAL EDP SYSTEM 


In the earlier analysis of chapters two, three and four, each 
division's operation was treated as a separate entity and a 
conceptual EDP system was proposed for the various applications 
without regard to integrating the four basic components of 
systems analysis namely the processing mode, data base, file 
design and the applications required by the user. The triangular 
effect of these four components as they relate to the feasibility 


study is illustrated below: 


Processing Mode File Design 
ieeeebatch - 1. Sequential 
2. Remote batch 2. Indexed Sequential 
3. On-line retrieval/ 3 Random 
Batch update ees Eo OE rl rE uILe 
WU, On-line retrieval/Update Aimwmeont ro. lec 
length 
byeecontre] led 
length 


ec) Inverted 


APPLICATIONS 

Ta eweeayroll 

Pee, CGWerect File Inquiry 

3. Contract File Update 
The remaining sections of this chapter will discuss the following 
items: 1) review the data base files proposed for chapters two, 
three and four, 2) analyze the various processing modes mentioned 
above, 3) discuss the various file design considerations, 
4) review the applications of the three divisions and determine a 


coneceptional system and 5) provide criteria for evaluation of the 
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system and make recommendations for further research in determining 


the overall effectiveness of the system. 


Ae THE DATA BASE 

The data base proposed for the financial division eonsists of 
the “Payroll,” "Dictionary" and"“Money" files. For the procurement 
Gavesmon the filles proposed consists of the "Annual I,D. Contract" 
daa O.1.P. Contract" files and finally the program managers 
Bio tome tiles Ce@nsisted of the “Contract,” "Name," and "P.M." 
files. The hierarchic data structure approach is used for the 
above mentioned files and is shown in figure 19 [Ref. 1]. The 
Peperren record i the hicrarchy is called a master record and an 
@niferior record is called a detailed record. In addition, a 
detail of -one record may be a master of another record. The net- 
work sulheutaie of the hierarchic file structure is illustrated in 
mere 20.5 For each file in the figure, a list of the data elements 
associated with that file are included. From examiniation, it is 
conceivable that the "Annual I.D. Comtract =riletand the VOQ.T.P. 
Contract" file, even though each is a master record, may be merged 
into a single master file because they contain the same data 
elements with the exception of the elements, "Contract Elapsed 
Date" and "EDD." Thus, the new merged file would contain seven 
elements vice the twelve data elements that now exist. In addition, 
other common data elements are employee name, social security 
number, contract number, status, material required, job order num- 
ber and dollar amount. Although it is not presently known what 
file design will be used, these data elements are candidates for 


fein: aa a key Dareetary described in a subsequent section. 
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B. THE PROCESSING MODE 

tie datierent processing modes considered in the analysis 
consisted of batch, remote batch, on-line retrieval/batch update 
and on-line retrieval/update. In the strict batch processing 
mode, users prepare their programs, punch them on some input media 
such as cards and then submit them to an operator for execution. 
User programs are input to the computer in‘batch. The operating 
system software would read one program at a time into the machine 
and execute it according to some predetermined discipline and 
write out the results on some output device Such as a printer. 

The operator would retrieve the printed output and return it along 
with the input card deck to the user. Thus, the user's only con- 
tact with the system is through a slot in the ADP section where 
he/she deposited cards and retricved the output. This mode of 
operation is Suitable for many types of production runs; i1.e., 
processing against written and debugged programs that are used 
again and again. However, with this mode there is a time lag, or 
turnaround time, of anywhere from a couple of minutes to several 
days depending on the users distance from the EDP center and the 
computer center's system characteristics. Therefore, if response 
Mminewis a eritical factor in the user’s requirements this mode of 
processing may not be adequatc. 

Within a remote batch processing mode environment, the user 1s 
physically remote from the computer Facility. The user provides 
requests from terminals to run certain production programs in the 
batch mode at the EDP centcr. The output may be printed at the 
remote location of the user or at the computcr center. As far as 
the user is concerned he has made direct contact with the central 


processing unit for his reguest. As far as the computer is 
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conccrned,however, the request is treated in the batch processing 
feces ene reason tor this difference in concept is that the 
Beclest, once 1t leaves the terminal, is put in a job queue and 
processed according to some determined servicing discipline. This 
mode of processing is desirable for a user that does not own or 

have a computer center dedicated to his work requests and the output 
generated is not required immediately. 

The on-line retrieval/batch update processing made consists 
of the user employing some on-line device such as a terminal to 
immediately seize the central processing unit and interrogate the 
data base directly. However, it any update to the data base is 
required, the user makes the request on the terminal, feeds the 
information to some off-line storage device (e.g., magnetic tape) 
and at the end of the day's operation this data iS processed ina 
batch mode. This processing mode may be desirable if the user 
needs to retrieve thefiles on-line but file updating is not 
required as rapidly. 

Finally, the completely on-line retrieval/update processing mode 
allows the user to seize the central processingunit and hold it 
until the inquiry or update is complete. This type of processing 
is sometimes called processing in real time. Real-time 
processing implies that the computer receives data, processes it, 
and returns results quickly enough for these results to be utilized 
in the continuation of the task being conducted. Many operation 
don't require an on-line updatc because the manager or Supervisor 
foaioeecoine to be im a positioneto make an immediatc decision on 


thes basis of the output eecnematcd, so a batch update would sufficc. 
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C. Shier rLeE DESUGN 

There are many options available for file design, but for the 
purpose of this study the file designs considcred consisted of 
sequential, indexcd sequential, random, and list structures with 
emphasis on uncontrolled length, controlled length and inverted 
files. 

With a sequential file design, the logical and physical order 
of the records are the same. Generally, the records in a 
sequential file are in lexicographic order of the values in some 
particular field or fields within the records. The fields that 
determine the sequential order are called keys. For instance if 
the field "Name" was a key the file would be ordered alphabetically. 
If a key is uSed in searching a file, it is relatively easy and 
quick to retrieve a number of records in sequence or to determine 
if a particular record is present in the system by performing a 
sequential search on the file using the key. For applications that 
require the use of a magnetic tape, the sequential file design is 
the only- option that is open to the user because the magnetic tape 
can only be searched using one key at a time. The major dis- 
advantaee Of a sequential file structure search lies in the fact 
that each and every record in the file must be examined if the 
search involves a field which is not the key for the file. 

With an indexed sequential file design, records are stored in 
sequential order as on magnetic tape. However, an indexed sequen- 
tial file design organization takes advantage of the cylinder 
structure of the particular direct access file to provide indexes 


Gi@ieindke it possible to locat® wa specific file record with only 
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@me seck delay. A two-level index is used. The first index is 
peevilinder index {e-.¢., a table containing the control key of the 
iast record stored in each cylinder as the argument and the 
cylinder number as the function of the table) and the second level 
index is the track index (e.g., another table whose arguments are 
the contro]. keys of the last record on each track and whose 
function values are the associated track addresses). An example 

of an indexed sequential file is illustrated in figure 21. When 

a file is in use, the cylinder index is maintained in main memory. 
If it is desired to find a record in figure 21 corresponding to the 
souurol key 0058/7, first, a table look-up on the cylinder index is 
performed with 00587 as the search argument, finding the first 
argument greater than or equal to 0058/7. Since 00587 is greater 
than 0075 and less than 00983 the record is determined to be in 
cylinder 003. Thus a seek is performed on cylinder 003 and its 
i’rst track ts read, placing the track index for cylinder 005 in 
memory. Again a table look-up is performed using 00587 as the 
search-argument. This search reveals that the record is in track 
03 of this cylinder, so one finds that the second record is the 
one that is desired. This whole procedure consists of a table 
look-up, one file seek, a read, another table look-up, another 
read, and examine the track to find the record. The advantage of 
iiewtilerdesiemeis tnat Ehe time to find a record 1s not as great 
as with a sequential file design because only one seek is performed 
and the time involved in table look-ups is small. The disadvantage 
with this design involves the handling of additions to the filc. 
Since the records are tight packed into the file tracks, there 


is no room for new records unless extra space is provided. 
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Generally, list strueture file design teehniques fall into 
two classes: multiple threaded lists (eontrolled and uncontrolled 
length) and inverted lists. In a multiple threaded list 
(uneontrolled length), there is a direetory that eontains a list 
of keys. In addition to the key name and value, a link address 
whieh indicates the first reeord on the direet aeeess storage 
device (DASD) is also stored in the key field. The output of the 
key directory is a fixed length reeord eontaining the key/head of 
list address/list length. A sample multiple threaded list is 
shown in figure 22. The head of list address is represented 
symbolieally as An, where n is a numerie representing a mass 
memory address. Reeords within the file area are represented as 
dots along the thread emanating from the output level of the key 
directory. Thus, the J list begins at address A3 and eontains 
six reeords. As indieated in figure 22, the fourth record on the 
J list is also the seeond reeord of key T beeause of the list 
intersection. This ’reeord has not becn labeled with an address 
in the figure beeause it is not a head of list record since the 
head of the T list is at All; however, there would be a link 
adaress pointing to this record comtained within the record at 
All. If, then, a query conjunetion JT were to be searehead in 
this file, the Key Directory Decoder would deeode both J and T and 
examine the respeetive list lengths at the output of the 
directory. Sinee the J list is shorter, eontaining six records as 
@epesced Lo eight for the f list, the J list would be searehed, 
thus requiring six random searches within the file area. Each 
aecessed record must be exonamecc 1m eore Lor the joint oceurence 


HieieeeWwatiethas type of file design a DASD must be used because 
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of the random searehes required. The greatest disadvantage of the 
multiple threaded list is that in order to respond to a ecnjunction 
of terms like J interseetion T, it must aeeess from the DASD and 
transfer to eore all reeords on the shortest list for examination 
in the proeessor, even though the interseetion of these lists, 
whieh satisfies the query, may be mueh smaller (in the example, 
Six reeords are queried for one interseeted reeord). The 
principal advantages of the multiple list (uncontrolled length) 
file organization are programming simplicity and update flexibility. 
itmeene inverted list file organization system, all link 
addresses have been removed from the file area and appear instead 
emeeene Output of the key directory. This will result in a 
eonsiderably Jarger directory than the multilist system although 
the total Wane usage is no greater because these same link 
addresses no longer appear within the file reeord. ‘The lists are 
variable length reeords that must be maintained in a monotonie 
sequenee for efficient logieal manipulation. The seareh for the 
joint oecurrence of terms is aeeomplished by list interseetion 
within the direetory and the conjunction of a nonnegated key with 
a negated key is accomplished by removing from the nonnegated 
key's list of addresses all those that appear on the negated list. 
Eaeh of the two deseribed logieal funetions are greatly expedited 
if the list addresses are stored in monotonie sequence, since only 
a single pass through the two lists is required. The prineipal 
advantages of the inverted list over the multilist file 
organization is that the list interseetion or merge proeess is 
considerably more cfficient simece it is performed on eompaet, 


sequeneed lists rather than requiring a random aecession for cach 
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mecerd on the fist. Also, it is a good file organization for 
data retrieval, especially when it is not known in advance what 
keys the user will require to process data. The disadvantages 
of the inverted list system are that a working or staging area is 
required in order to perform the logic processing and the list 
records, being variabie length, should include some reserve if 
real-time updating is to be allowed. 

When discussing the multilist (controlled length), it should 
be noted that multiple lists (uncontrolled) and inverted file 
organization are special cases of multilists where the former has 
MictecGonmtrol of intianity and the latter has list control of unity. 
meas. Controlled Jengcth multilists are actually partially 
inverted files. The special case of controlled length multilists 
considered ia thas Study is the Gelli@lar partation File design. 
tiewiasis of ethe cellular partition is to define logical cellular 
boundaries throughout the DASD medium into which the records may 
be placed according to some predetermined storage stratcgy. A 
Sample cellular multilist file organization is shown in figure 23 
with the predetermined length being three. Since the cell is 
part of the record address, the address notation Am.n/L is used 
Wieee mm adentities the cell in which a given lists begins, 

"n' jdentifies the mass memory address and "L" identifies the 
length of the record. Consider the query JT. An cxamination of 
the output level of the directory shows that list J contains sub- 
iiieterthiat are wholly contained with Cells 0, 1, ¢ and list 
emetnis 3. 2 and 3; therefore, one cannot expect to find a 
conjunction of J and T in any cells that are not contained within 


the cell intersection between the head of list addresses of J and T. 
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tifaeers, List @§@ Contains a head of list address in Cell O but list 
T does not; therefore, no intersection of JT cxists in Cell O be- 
cause list T does not appear in Cell O. Similar reasoning applics 
to Cell 3. Therefore, the search on the conjunction JT would be 
limited to those sublists J and/or T contained only in Cells 1 and 
2; furthermore in Cell 1, either list J or T may be searched be- 
cause they are the same length however, in Cell 2 list J is pre- 
ferred because it has a length of 1 versus list T whose length is 
2. The search would issuc an I/O command against both addresses 
in the J listing. The entire search would be effected in three 
random accession times rather than six. The advantages of this 
file design are that random access can overlap (if permitted by 
the DASD configuration) provided the "next records to be accessed" 
are in different cells and the programming of this structure 1s 

no more difficult than the programming required for the multiple 


(threaded) list. 


ee APPLICATIONS 

A review of the applications of the, financial division 
indicated that the payroll application was the only one that 
should be automated in the near future. This application con- 
sisted of updating the master payroll file weekly in order that 
the magnetic tape could be sent to NSC Oakland. For this appli- 
cation a batch mode should be utilized because there 1S no re- 
quirement for frequent inquiries to the file nor is the speed of 
Pespolsemtine 4 critical factor. It is further recommended that 
the "MONEY" file (figure 2) be designed as a sequential file be- 


cause File access is generally for a yroup of records vice a 
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single reeord and these accessed records are copied onto magnetie 
tape for submission to Oakland. 

The procurement division's applications eonsisted of updating 
and demand query of eertain fields of the "Annual I.D. Contraet" 
maa "O.!.P. Contraet" files. Sinee inquiry to these files is 
primarily on demand and then for only seleeted reeords, some eon- 
figuration of an on-line random access file system is indieated. 

It is reeommended that an on-line retrieval/bateh updating system 
be utilized for this application since the user will be interested 
in the eurrent status of various records. If the reeords require 
updating the user would generally not be in a position to make an 
immediate deeision on the update information, even if it was done 
on-line, hence a batch update mode is reeommended. Most of the 
fields cf the "Anmnual I.D." and "0.T.P. Contract" files will not 
require key dietionaries but the keys tnat do require key dietion- 
aries will have to be detailed (e.g., the keys of the dollar amount 
field may be broken down for every one-hundred dollars). Thus it 
seems obvious to use a fully inverted list for this reason. How- 
ever, on eloser inspeetion one finds that the disadvantages as- 
sociated with this file design as mentioned above would negate 

any advantage that existed with using an inverted file structure 
organization. Thus, the file design recommended is the multilist 
(Cellular partition), with this design the advantage of an inverted 
list exists without the problem of requiring additional work spaee 
as required with a fully inverted list. 

Finally, the only application for the program managers division 
that requires automation is demand inquiry of Lhe "Contract" and 


miame'’ files. With this application, fast response time is 
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important, therefore, some on-line random access file system is 
required. Since the program manager's division applieation is 
the same as the procurement division (with the exeeption of up- 
dating) it is reeommended that the same system be incorporated 
for the program manager's division. 

The results of the analysis indicate that the system should 
operate in two modes. At the top level of operation, there is an 
on-line system communieating with user terminals and vice versa. 
At the lower level there is the batch system for updating records 
and files on a predetermined schedule arranged by NAVELEX. Two 
file design organizations are maintained namely, sequential and 
multilists (Cellular partitions). The system shown in figure 24 
encompasses all the hardware required to perform the applications 


of the three divisions into one system for NAVELEX, 


Eee EVALUATING CRITERIA 

To further evaluate the computer system and file organization 
proposed, one must consider a set of performance and cost factors. 
The performance criteria that should be eonsidered are recall ratio, 
preeision ratio, eoverage and response time and of these the most 
important factors are reeall and precision. The reeall ratio is 
defined as: 


number of relevant doeuments retrieved by the system 


total number of relevant documents containcd in the system 
and the precision ratio is defined as: 


number of relevant documents retrieved by the system 
total number of documents retrieved by the systcm 


Although response time is important it must be a secondary con- 
sideration to preeision and recall. Finally the eoverage that the 


system provides is important because presumably, a user will not 





LIN 


Ad VL 


he oinsTy 


XTISAVN 
flere 


WaLSAS ddd ‘IVNLdaONO0O 


YALNdWOOIN IW 





madly aa 


duvo 





AAW dai el 


nk) 


62 





even approach the system unless he feels that its coverage is 
such that it will be able to contribute to satisfying his infor- 
mation needs. However, comprehensiveness of coverage is really 
only of concern to the user who requires high recall and the 
requestor with a iow recall requirement on the other hand, may 
not be particularly concerned about coverage. 

The cost factors that have to be considered are the computer 
time used in searching and the frequency of use of the system. 
In machine terms the computer time used will depend on the size 
of the data base, the type of search (e.g., serial, inverted) 
and the number of records found. One point to note here is that 
the time taken in search with an inverted file system increases 
imeaimost direct proportion to the number of record in the gqucry, 
whe reas Teac of each additional record on speed of search 
in a sequential system is normally less than the effect of the 
inverted system. If the frequency of use of the system is great 
the net overall cost of the system goes down. It should be noted 
here that if too many users are allowed access to the system, it 
may become saturated and give slow turnaround time thereby dis- 
couraging potential users. By considering the above criteria, 


the system chosen will likely be more compatible with the user's 


needs. 


F. ADDITIONAL STUDIES REQUIRED 

The system presented is by no means specific to the tailored 
needs of NAVELEX. Additional research should be done to determine 
ihe new tile desien would begwecquircd in the future. This may 


be accomplished by questioning the users on the expected [requency 


63 





of file inquiries or what new capability should be developed to 
meet future needs. It should be noted that with each new capa- 
bility some amount of complexity is going to be introduced in 
maintaining any complex file design. Another method of review- 
ing and projecting new demands on the system is to do a statis- 
tical analysis of the frequency that data fields are accessed to 
ascertain if the present file system needs to be modified. Final- 
ly, a study should be initiated to determine if NAVELEX should 
buy pre-packed routines for their system or do their own in-house 
software development. There are trade-offs with this approach 
namely, if a pre-packaged routine iS purchased, the user semen 
have to be proficient in the software language. On the other 
hand modification of the programs by the user may be very diffi- 
eult. Obviously more studies are required before NAVELEX actu- 
ally aequires a data base management system and it's associated 
operating system. It is hoped that the proeedures described in 


this paper will provide useful guidanee to NAVELEX in the develop- 


ment of automated data processing systems. 
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